Same comment as I made on #1232: please note the libraries that are updated in this PR, and any interesting changes in behaviour.

@bboreham hi, take an example that why go-grpc-middleware is mentioned and grpc-gateway is not:

# GO111MODULE=on go mod why github.com/grpc-ecosystem/grpc-gateway
# github.com/grpc-ecosystem/grpc-gateway
(main module does not need package github.com/grpc-ecosystem/grpc-gateway)
# GO111MODULE=on go mod why github.com/grpc-ecosystem/go-grpc-middleware
# github.com/grpc-ecosystem/go-grpc-middleware
github.com/cortexproject/cortex/pkg/util/grpcclient
github.com/grpc-ecosystem/go-grpc-middleware

use go mod why easily to explain.

Also, grpc-gateway is in go.sum indeed:

# git grep grpc-gateway
go.sum:142:github.com/grpc-ecosystem/grpc-gateway v0.0.0-20190311121628-6523154b0128/go.mod h1:vNeuVxBJEsws4ogUvrchl83t/GYV9WGTSLVdBhOQFDY=
go.sum:143:github.com/grpc-ecosystem/grpc-gateway v1.5.0/go.mod h1:RSKVYQBd5MCa4OVpNdGskqpgL2+G+NZTnrVHpWWfpdw=
go.sum:144:github.com/grpc-ecosystem/grpc-gateway v1.6.3 h1:oQ+8y59SMDn8Ita1Sh4f94XCUVp8AB84sppXP8Qgiow=
go.sum:145:github.com/grpc-ecosystem/grpc-gateway v1.6.3/go.mod h1:RSKVYQBd5MCa4OVpNdGskqpgL2+G+NZTnrVHpWWfpdw=
......

If we depend on one project A, but A does not have go.mod, the dependence of A would be auto found by go mod tidy refer to doc:

If a dependency of your module does not itself have a go.mod (e.g., because the dependency has not yet opted in to modules itself), or if its go.mod file is missing one or more of its dependencies (e.g., because the module author did not run go mod tidy), then the missing transitive dependencies will be added to your module's requirements, along with an // indirect comment to indicate that the dependency is not from a direct import within your module.

BTW, for go mod, no need vendor. Keep vendor and dep config to support dep and in future, they would be removed if not support dep.

Thank you for answering the subordinate question.

For clarity, my main request is for a list of the changes to dependency versions, and for some analysis of what is different. This is to guide what we should watch out for when updating.

i compare Gopkg.lock and go.mod to get following list:
since different rule between dep and go mod, for old version, if no version in Gopkg.lock, i use revision
@bboreham you can double check it.

Having a list is a good step, but before I deploy in production I like to know what behaviour has changed.

I.e., scan the release notes of each dependency and flag anything that may be relevant.

You’re right it’s a big list. Maybe we can divide and conquer?

Having a list is a good step, but before I deploy in production I like to know what behaviour has changed.

It is hard to cover all cases, while now all tests pass.
Too many projects base on this, from my side, get to know what behaviour has changed is very tough.

You’re right it’s a big list. Maybe we can divide and conquer?

Agree, which part does we begin?

Start at the top of the list?
Maybe call out “I will do the first 5” to avoid duplication?

I'll start:

First line - cloud.google.com/go was ed41f43dafb8 now v0.28.0 - I can't find where Google publishes release notes for this library. Punt and come back.

Second line - contrib.go.opencensus.io/exporter/ocagent was v0.2.0 now "-". But the files are not deleted from vendor/contrib.go.opencensus.io by this PR, they are updated. For instance https://github.com/cortexproject/cortex/pull/1303/files#diff-1151b378d60e59d0ef038ae0f47bcf9dR4
Is this an error in your method for listing changes?
Same for the next two lines.

github.com/Masterminds/squirrel was 20f192218cf5 now v0.0.0-20161115235646-20f192218cf5 - this is actually the same commit. Could make this clearer in the list.

Is this an error in your method for listing changes?

refer this comment, i only compare between Gopkg.lock and go.mod, not go.sum or vender, as i said in the beginning of comment.

github.com/Masterminds/squirrel was 20f192218cf5 now v0.0.0-20161115235646-20f192218cf5 - this is actually the same commit. Could make this clearer in the list.

It is difference rule between go dep and go mod, let us update list during check :)

@bboreham hi, edit list here is too bad, i create a google docs, you can edit it.

For vendor change, i will remove commit about vendor so that all commits only relate to go mod not go dep. WDYT?

@bboreham hi, any update? The list i has finished.

My objective is to know what changed, before I have to support a change in production.

The size of diff in this PR has come down from +900,000 to +100,000, which is good, but still I do not see a change in your table that matches this change in the code:
https://github.com/cortexproject/cortex/pull/1303/files#diff-d2af11b35109d03a552583a9464bdf56R107

I appreciate you don't know either, I'm not saying this is bad. I am saying I can't approve something I don't understand.

@bboreham thanks for response, i have remove changesd about vendor.

I get more knowledge in this process, and i find that my env not clean.
I run in a container to ensure clean env then update mod, the list also has been updated.

Thanks for the PR @daixiang0! @gouthamve is going to do a build of this and stick it in our dev env to test things out. If all is well, we should be able to get this merged.

FYI I tried deleing vendor and running go mod vendor, and there were no git changes. Good work!

Has anyone done a forwards/backwards compatibility check on the new protobuf library?
See also #1370

Has anyone done a forwards/backwards compatibility check on the new protobuf library?

We've done 3 rolling upgrades (two dev envs and one prod env) and didn't hit any problems.

• github.com/gogo/protobuf has gone from v1.1.1 to v1.2.1, which seem to just be a sync with golang/protobuf 1.2: https://github.com/golang/protobuf/releases/tag/v1.2.0
• github.com/golang/protobuf has gone from v1.2.0 to v1.3.1, which seem to be them migrating to modules.

I can't see anything that might indicate a compatibility change - and thats kinda the whole point of protobufs.

LGTM

thats kinda the whole point of protobufs

strangely this did not save us in #938